home *** CD-ROM | disk | FTP | other *** search
- Path: goanna.cs.rmit.EDU.AU!not-for-mail
- From: ok@goanna.cs.rmit.EDU.AU (Richard A. O'Keefe)
- Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2
- Subject: Re: Hungarian notation - whoops!
- Date: 15 Feb 1996 15:17:20 +1100
- Organization: Comp Sci, RMIT, Melbourne, Australia
- Message-ID: <4fuc4g$ovu@goanna.cs.rmit.EDU.AU>
- References: <4fms62$c0p@goanna.cs.rmit.EDU.AU> <824143624snz@genesis.demon.co.uk>
- NNTP-Posting-Host: goanna.cs.rmit.edu.au
- X-Newsreader: NN version 6.5.0 #0 (NOV)
-
- Lawrence Kirby <fred@genesis.demon.co.uk> writes:
- >Sure it is not difficult to implement sign-magnitude integer operations
- >but you would have to add extra CPU instructions in order to do so.
- >2's complement has the big advantage that it can be done using the same
- >instructions in many cases as unsigned arithmetic.
-
- This argument turns out to be incorrect, and on two grounds.
- To start with, several modern RISC systems have two sets of arithmetic
- instructions anyway. For example, the SPARC V8 Architecture Manual
- lists
- - duplicate integer loads (LDSB, LDSH, LDUB, LDUH)
- - duplicate multiply/divide (UMUL, SMUL, UMULcc, SMULcc,
- UDIV, SDIV, UDIVcc, SDIVcc)
- It already has 6 integer add and 6 integer subtract instructions; one more
- of each would hardly be a huge increase. In addition to that, the Motorola
- 88000 has duplicate add and subtract instructions (5 signed adds, 5 unsigned,
- 5 signed subtracts, 5 unsigned). These I looked up; from memory the R3000
- also has two sets of add and subtract instructions, but I can't look that up.
- The Intel 80960 has
- - addo, subo, mulo, divo, remo, shlo, shro, cmpo (unsigned)
- - addi, subi, mulo, divi, remi, shli, shri, cmpi (signed)
- which I just looked up.
-
- Since having two sets of integer instructions is _already_ common, making
- one of them sign-and-magnitude would do _nothing_ to the opcode space.
-
- But it gets better: if you don't have to worry about C, you have no
- particular reason to _want_ unsigned arithmetic. I used a B6700 for
- years, writing Fortran, COBOL, Pascal, Algol, Lisp, and SNOBOL, and
- never noticed that unsigned arithmetic wasn't there because there wasn't
- anything I wanted it for. (Note that you can do all the bit twiddling
- you want on signed numbers, you don't need unsigned for that.)
-
- >This is a non-issue. If you treat any expression resulting in 'the most
- >negative 2's complement integer' as an illegal result as far as your
- >code is concerned then you are back to the same situation as if you
- >were using sign-magnitude.
-
- Sorry, this is a _real_ issue. It's not _me_ that has to treat -2**(n-1)
- as an illegal result, it's the _hardware_, and it _doesn't_. There's no
- compiler option for any of the compilers I use to make it do that. Most
- of the compilers I use don't bother to check _any_ arithmetic results,
- and one SPARC Pascal compiler I used to use got some of the checks it
- did bother to do wrong.
-
- >So as you can see the overall effect is the same in both cases.
-
- The point is that 2s complement adders _don't_ report -2**(n-1) as overflow,
- don't have a bit in the program status word to make them do it, and so
- require extra instructions to check for wrong answers. The shortest sequence
- I can think of on a SPARC to check for overflow is
-
- ADDcc dest, src1, src2
- TVS <some trap number>
- CMP dest, <a register holding -(2**n-1)>
- TE <same trap number>
-
- which is going to take 4 times as long as a plain add, or would if I could
- get a compiler to generate it.
-
- >Do you check every signed integer operation for overflow (barring the ones
- >you can prove can't overflow)?
-
- Damn straight I do, *if* the compiler will let me.
- I also believe in having the results checked even if I _have_ proved
- they can't overflow; I've made mistakes in proofs before.
-
- I would remind readers that one reason some of the modern chips have
- signed as well as unsigned operations is that the signed operations
- DO raise an exception on overflow.
-
- >Whether the answer is yes or no you are no worse off using 2's complement
- >that sign-magnitude (but for different reasons).
-
- This conclusion makes no sense. There is no reason to expect sign and
- magnitude arithmetic to slow down a computing *system* (though it could
- make a difference to the area of the ALU). It simplifies the properties
- of arithmetic. And it cannot be simulated without moderately high cost,
- and in any case that simulation is NOT available.
- --
- Election time; but how to get Labour _out_ without letting Liberal _in_?
- Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
-